home *** CD-ROM | disk | FTP | other *** search
/ Gigarom 1 / Gigarom Macintosh Archives (Quantum Leap)(CDRM1080320)(1993).iso / FILES / BBS / MUBBS / MUBBS112.CPT / MUBBS112 / MUBBS V1.1.2.cpt / MUBBS V1.1.2 / help / Happy Users / User Interface Guidelines
Text File  |  1992-02-08  |  9KB  |  137 lines
  1.  
  2. MUBBS User Interface Guidelines
  3.  
  4. 11/15/91
  5.  
  6. By N. Hawthorn
  7.  
  8.  
  9. Please try to follow these guidelines when creating a module for MUBBS. This will insure CONSISTENCY from the user's point of view, and make the BBS a pleasure to call.
  10.  
  11. Your comments are welcome on this matter, and your suggestions may be added to this file.
  12.  
  13. Many thanks to those who have contributed to MUBBS and supplied me with some of the following ideas and text.
  14.  
  15.  
  16. MUBBS User Interface Guidelines:
  17.  
  18. The greatest danger in a collaborative design process is that the result can end up looking like a patchwork, rather than a unified whole (kind of like the difference between a platypus and a dolphin).
  19.  
  20. Everyone has their own idea of what is "right" and what seems "natural" to them. This leads to INCONSISTENCY for the end user of a program. I good example can be found in DOS based machines.
  21.  
  22. If each programmer can follow some simple User Interface Guidelines when building his code, the user will be able to use the programmers creation to it's fullest without having to learn a new set of "actions" just to get the code to operate.
  23.  
  24. MUBBS will be known as a Sysop's dream BBS. He can modify it in any way, and configure it as he pleases. Hopefully by our example, Sysop's will keep their BBS's somewhat standard so that when we call them we won't have to waste our time figuring out what is what.
  25.  
  26. The way you make a BBS different is by supplying different INFORMATION and DISCUSSIONS (Forums, Pubs...). A Sysop hoping to draw a crowd to his BBS could have a different BBS program running, but if the information is the same as others around, it won't make a difference.
  27.  
  28.  
  29. MENUS:
  30.  
  31. The key to making the user feel at ease in operating a BBS is all in the MENUS.
  32.  
  33. MUBBS menus are formatted so that the first letter of a word indicates a choice. The word is spelled out to the user, so that it's easy to figure out what the choice does.
  34.  
  35. Example:
  36.  
  37.    *** Main Menu ***
  38.  
  39. >> Files, Messages, Userconfig, Logoff :
  40.  
  41. This is just too simple isn't it ? Your BBS can't be very large, there isn't enough choices on this menu !
  42.  
  43. When you start a Mac application you don't see much either. You get a BIG "woopie!" about box introducing the program, but then you see just the names of the menu choices above. Some of the menus are "standard" (File and Edit). But you have seen VERY complicated programs on the Mac so you know better. You know that looking through the menus allows you to get the "feel" of what the program does.
  44.  
  45. This will all be true of MUBBS. Menus lead to other menus that lead to other menus BUT, each menu is ASSOCIATED with a particular section/function. THIS IS HOW THE HUMAN BRAIN FUNCTIONS - ASSOCIATIVELY !! So, since we are interfacing with a human brain or "associative computer" we must keep this in mind.
  46.  
  47. I have gotten so many compliments from people who said that the BBS was very easy to learn and use it's not funny. The original MUBBS was only up for about 6 or 8 months !
  48.  
  49. You can make your logon screens as BIG and as BOLD as you want, but keep the menus simple. Keep the choices on one menu small. Group your choices together in small groups and give them a name (which is a menu choice to get to them).
  50.  
  51. Your BBS can have LOTS of functions, and believe me the user will find them. People love exploring. Your BBS will provide a great experience that no other BBS has !
  52.  
  53. The ">>" is just a standard way of indicating to the user that he is at a command line, and not looking at normal text. You can tell at a single glance that it's a menu. Include this in all your menus.
  54.  
  55. The "*** Main Menu ***" indicates what MENU the user is at, it could be "*** File Section Menu ***" when in the file section.
  56.  
  57. There is no need for a delimiter like "M)essages", the first letter is in UPPER CASE for menu choices. It's pretty simple for users to figure out that the first letter is the choice selector. If you need two words, do this:
  58.  
  59. >> Files section, Message section, User configuration, Log off :
  60.  
  61. This normally lengthens the menu and is not necessary in most menus. A single word like "User" works OK. Most users would try that menu choice and see where it leads anyway. From then on he would know what it does.
  62.  
  63. A comma "," and a space follow each choice to allow the user to divide choices quickly in his mind. The ":" is telling the user to input here.
  64.  
  65. "L" is reserved for "Logoff" and "Q" is for "Quit" and return to a previous menu. The rest is up to you and the Sysop using your Module. You should provide "L" at what would be considered your Module's main menu. If your menus go very deep (like 4 levels or more) you might want to reconsider making your program into two separate modules, but in that case you should supply a "L" so that the user doesn't have to back up several menus just to log out (keeps them from just hanging up on your BBS, a major Sysop "piss off" for sure).
  66.  
  67. One press of a key sends the user wherever he chooses. This is normally called "Hot Keys". MUBBS is always in "Hot Key" mode. The only problem is if a user logs in and gets line noise. In the future MUBBS may test for line noise and turn off the one key press feature for that call.
  68.  
  69. When you release your module to the public for use, include these standard menus. Your module should allow a sysop to change them any way they like, but most sysops will stay within these guidelines because of YOUR EXAMPLE, only changing the words when needed.
  70.  
  71. The things to remember when setting up your menus is to keep it short and simple. Large assortments of features all piled in one menu is for DOS users. Think "associative" when designing your module and or whole BBS. Remember what it is you're trying to interface to (a brain). Your users will thank you.
  72.  
  73.  
  74. FILES:
  75.  
  76. Selecting files from a BBS is always a interface problem. When a Front End is in use (see below) it will be much easier.
  77.  
  78. The default setting in MUBBS will make it so that the user does not have to type in a file name. He chooses it from a simple selection.
  79.  
  80. There should be a option to type in a file name, and to search globally for that file in all sections. Part of a file name entered would bring up a choice of files matching the partial word.
  81.  
  82.  
  83. DISCUSSIONS:
  84.  
  85. "Discussions" are like "Pubs" or "Forums" on other BBS's where people can post comments on subjects of interest.
  86.  
  87. There are lots of interests out there, and the list could get long. Remember the menu discussion above about short menus and divide the subjects up into groups.
  88.  
  89. There should be a feature to allow searching all or some of the subject for a keyword or words.
  90.  
  91.  
  92. SEARCHING:
  93.  
  94. Any "text" type search should allow words like "and" & "or" & "not" be used in a search string. Lower/Upper case is ignored. This keeps it simple and easy to use.
  95.  
  96. Example:
  97.  
  98. I'm looking for anything on joe or carol but not when it contains bill...
  99.  
  100. Enter Search String :joe or carol not bill
  101.  
  102. People don't normally need to search for "or" or "not". The "not" function will not work in all circumstances.
  103.  
  104.  
  105. USERS:
  106.  
  107. MUBBS will always support ALL users. Never leave anyone out just because they don't use your type of computer. You may run into that one person that makes your BBS a big hit because he was interested in what you have to offer.
  108.  
  109. All file types must be able to be handled. Screen size should be adjustable.
  110.  
  111. If possible you should check with people who have modems and these "major" computers and let them test out your module:
  112.  
  113. Mac, PC, Atari, Commodore, Apple.
  114.  
  115. There will also be people who have just terminals too. Remember these people will eventually get a computer, so treat them right ! (have ASCII sends).
  116.  
  117. If a Sysop chooses to cover one type of system he can. The ability to handle more will remain without causing problems.
  118.  
  119.  
  120. FRONT ENDS:
  121.  
  122. Plan on modifying your code in the future to support a "Front End". A program that the user runs on his computer at his end to interface over the modem to the BBS program. He just points and clicks like any other Mac (or *yuck* Windows) program and he gets what he needs.
  123.  
  124. This means that your code should be in many sections or "subroutines" that can be called separately. When a user clicks on a choice, you call your routine. There will be a global variable that tells you the user is using a front end.
  125.  
  126. As of this writing there is no code for a front end, but it wont be too long ! It would seem that a new set of modules would be called if there was a front end activated.
  127.  
  128. Modules MUST support normal access always. Front End access is a option.
  129.  
  130.  
  131. SPEED:
  132.  
  133. Always think SPEED in your code. If you have to run a long search, you must call a routine that allows other users to have CPU time.
  134.  
  135. Also figure out a way to increase the speed of your routines. Some new modems will be doing 19200 and beyond in the future.
  136.  
  137.